As used herein, the term native application refers to an application that is designed to run natively (i.e., without translators or other intermediary mechanisms) on an operating system executing on a processor-based computer system. In contrast, a managed application refers to an application that is not capable of running natively on the operating system, but is instead designed to run in an environment provided by a managed runtime executing on top of the operating system. The managed runtime manages the execution of the managed application and provides services thereto. Among other features, the managed runtime may provide a just-in-time compiler that converts the code of a managed application into code native to the operating system at runtime. By using managed runtimes, applications that have been compiled for a single architecture can be run on many different machines. Examples of managed runtimes include the Common Language Runtime published by Microsoft Corporation of Redmond, Wash., and the Java Runtime Environment published by Sun Microsystems of Santa Clara, Calif.
When the execution of a managed application is initiated on a processor-based computer system, the operating system is prompted to load the appropriate managed runtime to facilitate execution of the managed application. In certain computing environments, it is now possible to concurrently run more than one managed runtime in a single process. This feature enables a native or managed application to invoke the features of one or more additional managed applications, wherein each managed application is supported by its own managed runtime. One advantage of the ability to concurrently run multiple managed runtimes in a single process is that managed applications written for different versions of the same managed runtime can be concurrently executed within the same process without concerns about compatibility. For example, managed applications written for different versions of the Common Language Runtime may be executed concurrently within the same process by loading the appropriate version of the Common Language Runtime to support each managed application.
Certain challenges arise when attempting to operate a computing environment in which more than one managed runtime can run concurrently in the same process. For example, when two or more managed runtimes are running concurrently in the same process and one of the managed runtimes fails unexpectedly, each managed runtime may independently attempt to report an application error even when the managed runtime did not itself cause the failure. This results in the generation of multiple error reports, with only one of the reports coming from the failing managed runtime, which has the context of the original failure to be used to generate a useful error report. The generation of multiple error reports in this manner provides a poor user experience. Furthermore, the generation of multiple error reports in this manner could mislead subsequent investigations into the cause of the failure since only the error report generated by the failing managed runtime is useful for investigation.
In order to provide a reasonable error reporting user experience, it would appear that some sort of cooperation is required between the different managed runtimes running in the same process. For example, let it be assumed that a failure occurs due to an unhandled exception thrown by a first managed runtime executing on a thread and that a second managed runtime owns the base of the thread. In this case, only the first managed runtime will have the information necessary to produce a useful error report. However, due to the way exceptions are managed in some computing environments, only the second managed runtime may have the information necessary to determine whether the exception is fatal and that an error report should be triggered. Since the first and second managed runtimes are designed to be unaware of each other and do not communicate directly, the result may be that only the second managed runtime produces an error report, but the error report is not useful. Other possible results due to this lack of cooperation between the managed runtimes is that no error reports are generated or that multiple error reports are generated, but at best only one of the error reports is useful.
Commonly-owned co-pending U.S. patent application Ser. No. 12/358,708, filed on Jan. 23, 2009, describes a customized error reporting system that can be used to coordinate error reporting among multiple managed runtimes concurrently running in the same process. However, the error reporting facilities described in this application are provided as part of an operating system. As such, the approach to coordinating error reporting described in that application will only work in a system in which the operating system has been built or modified to include the described facilities. Otherwise, the concurrent execution of multiple runtimes in the same process will lead to the various problems described above.
What is needed then is a system and method for coordinating error reporting among multiple runtimes that are concurrently executing in the same process. The desired system and method should address one or more of the problems described above, including but not limited to the generation of error reports that are not useful and/or the generation of multiple error reports by the managed runtimes. The desired system and method should also address the problem(s) in a manner that is not dependent on facilities built or added into a particular operating system.